parallel network processing

ly, we consider an in-memory interface to cleanly separate the networking from the disk activity. This is equivalent to assuming that the server’s networking activity can be explicitly scheduled, in a manner that is independent from other server activity. Our results will apply to systems in which this is the case. We anticipate that in large-scale servers, independent network scheduling will be essential for meeting the real-time communication constraints derived jointly from media continuity and client buffering limitations. Thus, we do not consider software designs in which the network activity is inherently coupled with other processing (such as disk retrieval scheduling) and fine-grained, flexible and separable control of the network processing is not possible. The performance advantages unique to an “integrated” system design are by no means clear; for example, disk retrieval can be network driven even when network activity is explicitly scheduled. Note that the decoupling of the network and disk subsystem activity has precedent in the literature (e.g., [72]). Initially, we will assume that the processor resources required for network processing are continuously available. This is a reasonable base case in the sense that it reflects the implementation alternative in which network processing is scheduled with preemptive priority on a given processor set. However, relaxing the assumption would enable a more flexible overall system design, since the scheduling of non-network processing (including disk subsystem management activities) would be less constrained. Our exploration of the robustness of the policies with respect to unpredictable availability of processor resources will approximate the concurrent execution of non-network processing at equal priority. Such a study would be most suitably conducted through simulation parameterized by experimental measurement of the developed infrastructure. Non-network processing executing concurrently on other processors will create bus and memory contention, impacting execution of network processing. We will not be able to capture this effect experimentally; the impact could be evaluated analytically or through simulation. DEVELOPING THE NECESSARY INFRASTRUCTURE The disk simulation front-end. There are several possible approaches to generating the disk array trace which serves as input to the network implementation. Initially we will assume that disk blocks are always in memory, i.e., that the networking never waits for blocks to arrive from the disk subsystem. As an improvement, we may generate block arrival times with a simple disk array model (e.g., similar to the one used in [79])4. 4In that model, individual disks are modeled with a non-linear seek-time function, rotational latency, capacity and track/sector/cylinder configuration; data blocks are assumed to be distributed randomly across the disk surfaces; and SCSI bus transfer times and contention are not modeled. More sophisticated approaches would be to glue N K copies of a validated single-disk model together in a disk-array configuration (SCSI bus transfer times and contention would not modeled), or to acquire a validated parallel disk array simulator capturing SCSI bus contention and transfer characteristics.